5. Enabling SSL on Web Sites
SSL is a protocol for encrypting data that is transferred between a
client and a server. Without SSL, servers pass data in readable,
unencrypted text to clients, which could be a security risk in an
enterprise environment. With SSL, servers pass data encoded using
128-bit encryption.
Although Web
sites are configured to use SSL on port 443 automatically, the server
won't use SSL unless you've created and installed a valid X.509
certificate. When you install the Client Access server role on your
Exchange server, a default X.509 certificate is created for Exchange
Server 2010 and registered with IIS. In IIS Manager, you can view the default X.509 certificate by completing the following steps:
-
Log on locally to the Client Access server. Start IIS Manager. Click
Start, point to Programs or All Programs as appropriate, point to
Administrative Tools, and then select Internet Information Services
(IIS) Manager. -
In IIS Manager, select the server node and then double-click the Server Certificates feature. -
On the Server Certificates page, you'll see a list of certificates the Web
server can use. The default X.509 certificate for Exchange Server has
the name Microsoft Exchange and is issued to the Exchange server
configured with the Client Access server role. Click the certificate
entry, and then click View in the Actions pane to view detailed
information regarding the certificate. By default, this certificate is
valid for one year from the date you install the Client Access server
role.
For a long-term solution, you need to create a permanent certificate
for the Client Access server. This certificate can be a certificate
assigned by your organization's certificate authority
(CA) or a third-party certificate. To create a certificate for use with
Exchange and IIS, use the features provided by the Exchange management
tools. In the Exchange Management Console, you can view available
certificates for each server by selecting the Server Configuration node
in the left pane and then selecting the server you want to work with in
the right pane. In the lower panel of the details pane, you'll see a
list of available certificates. You can then work with the available
certificates in a variety of ways:
-
Right-click a certificate and then select Open to view the certificate. -
Right-click a certificate and then select Assign Services To
Certificate to view the services the certificate is registered with and
to assign services (if permitted).
To create a certificate, complete the following steps:
-
In the Exchange Management Console, select the Server Configuration
node in the left pane, and then select the server you want to work with
in the right pane. -
Right-click in the lower panel, and then select New Exchange
Certificate. This starts the New Exchange Certificate Wizard. Use the
wizard to create a certificate request file. -
Send the certificate request file to a third-party certificate
authority or your organization's CA as appropriate. When you receive the
certificate back from the CA, import the certificate. In the Exchange
Management Console, select the Server Configuration node in the left
pane, and then select the server you want to work with in the right
pane. -
Right-click in the lower panel, and then select Import Exchange
Certificate. This starts the Import Exchange Certificate Wizard. Use the
wizard to import the certificate file.
After you've installed the certificate,
you should test the certificate with an external client by accessing
OWA from a remote computer. Clients won't automatically trust
self-signed certificates or certificates issued by your CA. Because of
this, you might see an error stating that there is a problem with the
Web site's security certificate. In this case, follow these steps to
have the client trust the certificate:
-
Click the Continue To This Website link. When you continue to the
site, a Certificate Error option appears to the right of the address
field. -
Click the Certificate Error option to display a related error dialog
box, and then click View Certificates to display the Certificate dialog
box. -
On the General tab of the Certificate dialog box, you'll see an error
stating the CA Root Certificate isn't trusted. To enable trust, click
Install Certificate. This starts the Certificate Import Wizard. -
Accept the default settings by clicking Next twice and then clicking
Finish. Click OK twice. The browser will now trust the certificate, and
you shouldn't see the certificate error again for this client.
You also can test OWA connectivity by using the Remote
Connectivity Analyzer. In Exchange Management Console, select the
Toolbox node and then double-click the Remote Connectivity Analyzer
entry. Select the tests you want to run, click Next, and then follow the
prompts.
6. Restricting Incoming Connections and Setting Time-Out Values
You control incoming
connections to a Web site in several ways: you can set a maximum limit
on the bandwidth used, you can set a limit on the number of simultaneous
connections, and you can set a connection
time-out value. However, typically you wouldn't want to do any of this
for a Client Access server or OWA. OWA has its own timers based on
whether the end user is on a public/shared or a private computer. These
values are fixed and not affected by any restrictions or settings
discussed in this section.
Normally, Web
sites have no maximum bandwidth limits and accept an unlimited number of
connections, and this is an optimal setting in most environments.
However, when you're trying to prevent the underlying server hardware
from becoming overloaded or you want to ensure other Web sites on the
same computer have enough bandwidth, you might want to limit the
bandwidth available to the site and the number of simultaneous
connections. When either limit is reached, no other clients are
permitted to access the server. The clients must wait until the
connection load on the server decreases.
The connection time-out value determines when idle user sessions are
disconnected. With the default Web site, sessions time out after they've
been idle for 120 seconds (2 minutes). It's a sound security practice
to disconnect idle sessions and force users to log back on to the
server. If you don't disconnect idle sessions within a reasonable amount
of time, unauthorized persons could gain access to your messaging
system through a browser window left unattended on a remote terminal.
You can modify connection limits and time-outs by completing the following steps:
-
Start IIS Manager. Click Start, point to Programs or All Programs as
appropriate, point to Administrative Tools, and then select Internet
Information Services (IIS) Manager. -
In IIS Manager, double-click the entry for the server with which you want to work, and then double-click Sites. -
In the left pane, select the Web site that you want to manage, and
then click Limits in the Actions pane. This displays the Edit Web Site
Limits dialog box, as shown in Figure 3.
-
To remove maximum bandwidth limits, clear the Limit Bandwidth Usage
check box. To set a maximum bandwidth limit, select the Limit Bandwidth
Usage check box and then set the desired limit in bytes. -
The Connection
Time-Out field controls how long idle user sessions remain connected to
the server. The default value is 120 seconds. Type a new value to change
the current time-out value. -
To remove connection limits, clear the Limit Number Of Connections
check box. To set a connection limit, select the Limit Number Of
Connections check box, and then type a limit. -
Click OK.
7. Redirecting Users to Alternate URLs
Sometimes, you might find that you want to redirect users to alternate URLs. For example, you might want users to type http://mail.cpandl.com and get redirected to https://mail.cpandl.com/owa.
You can redirect users from one URL to another by completing the following steps:
-
Start IIS Manager. Click Start, point to Programs or All Programs as
appropriate, point to Administrative Tools, and then select Internet
Information Services (IIS) Manager. -
In IIS Manager, navigate to the level you want to manage. You manage
redirection for an entire site at the site level. You manage redirection
for a directory at the directory level. -
In the main pane, double-click the HTTP Redirect feature. This displays the HTTP Redirect page.
Note
With IIS 7.0 and IIS 7.5, HTTP redirection is an optional role
service. Therefore, if the HTTP Redirect feature is not available, you
need to install the related role service by using Server Manager's Add
Role Services Wizard.
-
On the HTTP Redirect page, select Redirect Requests To This Destination. -
In the Redirect Requests To This Destination text box, type the
Uniform Resource Locator (URL) to which the user should be redirected.
To redirect the user to a different server, type the full path, starting
with http:// or https://, such as https://mailer2.cpandl.com/owa. To redirect the user to a virtual directory on the same server, type a slash mark (/) followed by the directory name, such as /owa. Click Apply to save your settings.
8. Controlling Access to the HTTP Server
IIS supports several authentication methods, including
-
Anonymous authentication With anonymous authentication, IIS automatically logs users on with an anonymous or guest account. This allows users to access resources without being prompted for user name and password information. -
ASP.NET Impersonation
With ASP.NET
Impersonation, a managed code application can run either as the user
authenticated by IIS or as a designated account that you specify when
configuring this mode. -
Basic authentication
With basic
authentication, users are prompted for logon information. When entered,
this information is transmitted unencrypted (base64-encoded) across the
network. If you've configured secure communications on the server,
you can require that clients use SSL. When you use SSL with basic
authentication, the logon information is encrypted before transmission. -
Windows authentication
With Windows
authentication, IIS uses kernel-mode Windows security to validate the
user's identity. Instead of prompting for a user name and password,
clients relay the logon credentials that users supply when they log on
to Windows. These credentials are fully encrypted without the need for
SSL, and they include the user name and password needed to log on to the
network. -
Digest authentication
With digest
authentication, user credentials are transmitted securely between
clients and servers. Digest authentication is a feature of HTTP 1.1 and
uses a technique that can't be easily intercepted and decrypted. -
Forms authentication
With Forms
authentication, you manage client registration and authentication at the
application level instead of relying on the authentication mechanisms
in IIS. As the mode name implies, users register and provide their
credentials using a logon form. By default, this information is passed
as cleartext. To avoid this, you should use SSL encryption for the logon
page and other internal application pages.
When you install IIS 7.0 or IIS 7.5 on a Client Access server, you
are required to enable basic authentication, digest authentication, and
Windows authentication. These authentication methods, along with anonymous authentication, are used to control access to the server's virtual directories. A virtual directory is simply a folder path that is accessible by a URL. For example, you could create a virtual directory called Data that is physically located on C:\CorpData\Data and accessible using the URL https://myserver.mydomain.com/Data.
Table 2 summarizes the default authentication settings
for each directory. You should rarely change the default settings.
However, if your organization has special needs, you can change the authentication settings at the virtual directory level.
Table 2. Default Authentication Settings for Virtual Directories
|
VIRTUAL DIRECTORY |
ANONYMOUS AUTHENTICATION |
BASIC AUTHENTICATION |
DIGEST AUTHENTICATION |
WINDOWS AUTHENTICATION |
|---|
|
Autodiscover |
Yes |
Yes |
No |
Yes | |
ECP |
Yes |
Yes |
No |
No | |
EWS |
Yes |
No |
No |
Yes | |
Microsoft-Server-ActiveSync |
No |
Yes |
No |
No | |
OAB |
No |
No |
No |
Yes | |
OWA |
No |
Yes |
No |
No | |
PowerShell |
Yes |
No |
No |
No | |
Public |
No |
Yes |
No |
Yes |
As the table shows, the default public folder tree is accessible
through basic and Windows authentication. If you want to grant public access
to this folder tree or restrict the tree so that only Windows
authentication is allowed, you can do so by editing the individual
security settings on the related virtual directory.
The authentication settings on virtual
directories are different from authentication settings on the Web site
itself. By default, the Web site allows anonymous access. This means
that anyone can access the server's home page without authenticating
themselves. If you disable anonymous access at the server level and
enable some other type of authentication, users need to authenticate
themselves twice: once for the server and once for the virtual directory
they want to access.
The preferred way to manage authentication settings is to use the appropriate cmdlet in the Exchange Management Shell:
-
For ActiveSync, use Set-ActiveSyncVirtualDirectory. -
For Autodiscover, use Set-AutodiscoverVirtualDirectory. -
For ECP, use Set-EcpVirtualDirectory. -
Fur OAB, use Set-OabVirtualDirectory. -
For OWA, use Set-OwaVirtualDirectory. -
For PowerShell, use Set-PowerShellVirtualDirectory. -
For Exchange Web Services, use Set-WebServicesVirtualDirectory.
As an example, to disable basic authentication on the default ActiveSync directory, you would enter:
Set-ActiveSyncVirtualDirectory -Identity "cpandl\microsoft-server-
activesync" -BasicAuthEnabled $false
You can change the authentication settings for an entire site or for a
particular virtual directory by completing the following steps:
-
Start IIS Manager. Click Start, point to Programs or All Programs as
appropriate, point to Administrative Tools, and then select Internet
Information Services (IIS) Manager. -
In IIS Manager, navigate to the level you want to manage and then
double-click the Authentication feature. On the Authentication page,
shown in Figure 4,
you should see the available authentication modes. If a mode you want
to use is not available, you need to install and enable the related role
service using Server Manager's Add Role Services Wizard.
-
To enable or disable anonymous access, select Anonymous Authentication and then click Enable or Disable as appropriate.
Note
With anonymous access, IIS uses an anonymous user account for access
to the server. The anonymous user account is named IUSR_ServerName,
such as IUSR_Mailer1. If you use this account, you don't need to set a
password. Instead, let IIS manage the password. If you want to use a
different account, click Edit, and then click Set to specify the user
name and password for a different account to use for anonymous access.
-
To configure other authentication methods, select the authentication
method and then click Enable or Disable as appropriate. Keep the
following in mind:
-
Disabling basic authentication might prevent some clients from
accessing resources remotely. Clients can log on only when you enable an
authentication method that they support. -
A default domain isn't set automatically. If you enable Basic
authentication, you can choose to set a default domain that should be
used when no domain information is supplied during the logon process.
Setting the default domain is useful when you want to ensure that
clients authenticate properly. -
With Basic and Digest authentication, you can optionally specify the realm that can be accessed. Essentially, a realm
is the DNS domain name or Web address that will use the credentials
that have been authenticated against the default domain. If the default
domain and realm are set to the same value, the internal Windows domain
name might be exposed to external users during the user name and
password challenge/response. -
If you enable ASP.NET
Impersonation, you can specify the identity to impersonate. By default,
IIS uses pass-through authentication, and the identity of the
authenticated user is impersonated. You can also specify a particular
user if necessary. -
If you enable Forms authentication, you can set the logon URL and cookies settings used for authentication.
|
